Bemästra Formulärvalidering med Reacts `experimental_useFormStatus`

Formulär är grunden för webbinteraktion. Från en enkel prenumeration på nyhetsbrev till en komplex flerfasig finansiell applikation, är de den primära kanalen genom vilken användare kommunicerar med våra applikationer. Men i åratal har hantering av formulärstillstånd i React varit en källa till komplexitet, boilerplate och beroendeträthet. Vi har jonglerat med kontrollerade komponenter, kämpat med tillståndshanteringsbibliotek och skrivit otaliga `onChange`-hanterare, allt i strävan efter en sömlös och intuitiv användarupplevelse.

React-teamet har omprövat denna grundläggande aspekt av webbutveckling, vilket har lett till introduktionen av ett nytt, kraftfullt paradigm centrerat kring React Server Actions. Denna nya modell, byggd på principerna om progressiv förbättring, syftar till att förenkla formulärhanteringen genom att flytta logiken närmare där den hör hemma – ofta på servern. Kärnan i denna klientinriktade revolution är två nya experimentella hooks: `useFormState` och stjärnan i vår diskussion idag, `experimental_useFormStatus`.

Denna omfattande guide tar dig med på ett djupt dyk in i `experimental_useFormStatus`-hooken. Vi kommer inte bara att titta på dess syntax; vi kommer att utforska den mentala modellen den möjliggör: Statusbaserad valideringslogik. Du kommer att lära dig hur denna hook frikopplar UI från formulärtillståndet, förenklar hanteringen av väntande tillstånd och samverkar med Server Actions för att skapa robusta, tillgängliga och högpresterande formulär som fungerar redan innan JavaScript laddas. Förbered dig på att ompröva allt du trodde du visste om att bygga formulär i React.

Ett paradigmskifte: Utvecklingen av React-formulär

För att fullt ut uppskatta innovationen som `useFormStatus` tillför, måste vi först förstå resan för formulärhantering i React-ekosystemet. Detta sammanhang belyser de problem som detta nya tillvägagångssätt elegant löser.

Det gamla gardet: Kontrollerade komponenter och tredjepartsbibliotek

I åratal var standardmetoden för formulär i React mönstret med kontrollerade komponenter. Detta innebär:

• Att använda en React-tillståndsvariabel (t.ex. från `useState`) för att hålla värdet på varje formulärinmatning.
• Att skriva en `onChange`-hanterare för att uppdatera tillståndet vid varje tangenttryckning.
• Att skicka tillbaka tillståndsvariabeln till inmatningens `value`-prop.

Även om detta ger React full kontroll över formulärets tillstånd, introducerar det betydande boilerplate. För ett formulär med tio fält kan du behöva tio tillståndsvariabler och tio hanterarfunktioner. Att hantera validering, feltillstånd och inlämningsstatus lägger till ännu mer komplexitet, vilket ofta leder till att utvecklare skapar invecklade anpassade hooks eller vänder sig till omfattande tredjepartsbibliotek.

Bibliotek som Formik och React Hook Form blev framträdande genom att abstrahera bort denna komplexitet. De tillhandahåller briljanta lösningar för tillståndshantering, validering och prestandaoptimering. Men de representerar ett annat beroende att hantera och fungerar ofta helt på klientsidan, vilket kan leda till duplicerad valideringslogik mellan frontend och backend.

Den nya eran: Progressiv förbättring och Server Actions

React Server Actions introducerar ett paradigmskifte. Huvudidén är att bygga på grunden för webbplattformen: standard HTML `

`-elementet. Ett formulär med en serveråtgärd fungerar som en klassisk HTML-formulärinlämning – det kan fungera perfekt även om JavaScript misslyckas eller är inaktiverat. Detta är kärnan i progressiv förbättring.

När JavaScript laddas kapar React formulärets inlämningsprocess, förhindrar en fullständig sidoladdning och utför serveråtgärden asynkront. Detta ger oss det bästa av båda världar: motståndskraften hos serveråtergivna applikationer och den rika, interaktiva upplevelsen av en enskild sidapplikation (SPA).

Denna modell flyttar sanningens källa för affärslogik och validering tillbaka till servern (eller en serverliknande miljö). Klientsidskoden blir enklare, främst berörd av att återge UI baserat på *statusen* för den serverkommunikationen. Det är precis här som `useFormStatus` kommer in i bilden.

Under huven: Vad är `experimental_useFormStatus`?

`experimental_useFormStatus`-hooken är ett verktyg på klientsidan som är utformat för att ge information om den senaste inlämningen av ett överordnat ``-element. Det är en skrivskyddad hook som berättar för en komponent allt den behöver veta om formulärets inlämningsstatus utan att behöva några props som skickas ner.

Kärnfunktionaliteten

Föreställ dig en submit-knapp i ett stort formulär. Hur vet den här knappen när formuläret skickas? Traditionellt skulle du behöva skicka en tillståndsvariabel som `isSubmitting` ner genom flera lager av komponenter (prop drilling). Med `useFormStatus` kan knappkomponenten ta reda på denna information på egen hand.

Hooken måste anropas från en komponent som återges inuti ett ``-element. Den ger sedan statusinformation om den specifika formulärets livscykel.

Anatomi av `useFormStatus`-hooken

När du anropar `const status = useFormStatus()`, får du tillbaka ett objekt med följande nyckelegenskaper:

• `pending` (boolean): Detta är den mest frekvent använda egenskapen. Den är `true` om det överordnade formuläret för närvarande skickas in och `false` annars. Det är perfekt för att inaktivera knappar, visa laddningssnurror eller formatera väntande tillstånd.
• `data` (FormData): Ett objekt som implementerar `FormData`-gränssnittet. Den innehåller de data som skickades in med formuläret. Detta är otroligt användbart för att implementera optimistiska UI-uppdateringar – till exempel att visa en användares kommentar i en lista omedelbart efter att de skickat in den, även innan servern har bekräftat dess skapande.
• `method` (string): HTTP-metoden ('get' eller 'post') som används för formulärinlämningen.
• `action` (function): En referens till serveråtgärdsfunktionen som anropades under inlämningen.

Den gyllene regeln: Ett barn till ``

En kritisk regel att komma ihåg är att en komponent som använder `useFormStatus` måste återges som ett barn till ``-elementet som den spårar. Den kan inte vara i samma komponent som återger själva ``-taggen, eftersom den behöver komma åt formulärets sammanhang. Det är därför du nästan alltid kommer att se komponenter som en `` skapas separat för att hysa `useFormStatus`-logiken.

Ett enkelt exempel: Den smarta submit-knappen

Låt oss se det vanligaste användningsfallet i aktion. Istället för en standard `` kommer vi att skapa en komponent som är medveten om formulärets inlämningstillstånd.

Fil: SubmitButton.js

import { experimental_useFormStatus as useFormStatus } from 'react-dom'; export function SubmitButton() { const { pending } = useFormStatus(); return (

{pending ? 'Skickar...' : 'Registrera'} ); }

Fil: SignUpForm.js

import { SubmitButton } from './SubmitButton'; import { signUpAction } from './actions'; // En serveråtgärd export function SignUpForm() { return ( E-post:
); }

I det här exemplet är `SubmitButton` helt fristående. Den tar inte emot några props. Den använder `useFormStatus` för att veta när `SignUpForm` är väntande och inaktiverar sig själv automatiskt och ändrar sin text. Detta är ett kraftfullt mönster för frikoppling och att skapa återanvändbara, formulärmedvetna komponenter.

Hjärtat i frågan: Statusbaserad valideringslogik

Nu kommer vi fram till kärnkonceptet. `useFormStatus` är inte bara för laddningstillstånd; det är en nyckelmöjlighet för ett annat sätt att tänka på validering.

Definiera "Statusvalidering"

Statusbaserad validering är ett mönster där valideringsåterkoppling främst levereras till användaren som svar på ett formulärinlämningsförsök. Istället för att validera vid varje tangenttryckning (`onChange`) eller när en användare lämnar ett fält (`onBlur`), körs den primära valideringslogiken när användaren skickar in formuläret. Resultatet av denna inlämning – dess *status* (t.ex. framgång, valideringsfel, serverfel) – används sedan för att uppdatera UI.

Detta tillvägagångssätt överensstämmer perfekt med React Server Actions. Serveråtgärden blir den enda källan till sanning för validering. Den tar emot formulärdata, validerar den mot dina affärsregler (t.ex. "används den här e-postadressen redan?") och returnerar ett strukturerat tillståndsobjekt som anger resultatet.

Dess partners roll: `experimental_useFormState`

`useFormStatus` berättar för oss *vad* som händer (väntande), men det berättar inte *resultatet* av vad som hände. För det behöver vi dess syskon-hook: `experimental_useFormState`.

`useFormState` är en hook utformad för att uppdatera tillståndet baserat på resultatet av en formuläråtgärd. Den tar åtgärdsfunktionen och ett initialt tillstånd som argument och returnerar ett nytt tillstånd och en omsluten åtgärdsfunktion att skicka till ditt formulär.

const [state, formAction] = useFormState(myAction, initialState);

• `state`: Detta kommer att innehålla returvärdet från den sista körningen av `myAction`. Det är här vi får våra felmeddelanden.
• `formAction`: Detta är en ny version av din åtgärd som du bör skicka till formulärets `
  `s `action`-prop. När detta anropas utlöser det den ursprungliga åtgärden och uppdaterar `state`.

Det kombinerade arbetsflödet: Från klick till feedback

Så här fungerar `useFormState` och `useFormStatus` tillsammans för att skapa en fullständig valideringsloop:

1. Initial återgivning: Formuläret återges med ett initialt tillstånd som tillhandahålls av `useFormState`. Inga fel visas.
2. Användarinlämning: Användaren klickar på submit-knappen.
3. Väntande tillstånd: `useFormStatus`-hooken i submit-knappen rapporterar omedelbart `pending: true`. Knappen blir inaktiverad och visar ett laddningsmeddelande.
4. Åtgärdsutförande: Serveråtgärden (omsluten av `useFormState`) utförs med formulärdatan. Den utför validering.
5. Åtgärd returnerar: Åtgärden misslyckas med validering och returnerar ett tillståndsobjekt, till exempel:
   `{ message: "Valideringen misslyckades", errors: { email: "Denna e-postadress används redan." } }`
6. Tillståndsuppdatering: `useFormState` får detta returvärde och uppdaterar sin `state`-variabel. Detta utlöser en återgivning av formulärkomponenten.
7. UI-feedback: Formuläret återges igen. `pending`-statusen från `useFormStatus` blir `false`. Komponentet kan nu läsa `state.errors.email` och visa felmeddelandet bredvid e-postinmatningsfältet.

Hela detta flöde ger tydlig, serverauktoritativ feedback till användaren, helt driven av inlämningsstatusen och resultatet.

Praktisk mästarklass: Bygga ett flerfältsregistreringsformulär

Låt oss befästa dessa koncept genom att bygga ett komplett registreringsformulär i produktionsstil. Vi använder en serveråtgärd för validering och både `useFormState` och `useFormStatus` för att skapa en fantastisk användarupplevelse.

Steg 1: Definiera serveråtgärden med validering

Först behöver vi vår serveråtgärd. För robust validering kommer vi att använda det populära biblioteket Zod. Denna åtgärd kommer att finnas i en separat fil, markerad med direktivet `'use server';` om du använder en ramverk som Next.js.

Fil: actions/authActions.js

'use server'; import { z } from 'zod'; // Definiera valideringsschemat const registerSchema = z.object({ username: z.string().min(3, 'Användarnamnet måste vara minst 3 tecken långt.'), email: z.string().email('Ange en giltig e-postadress.'), password: z.string().min(8, 'Lösenordet måste vara minst 8 tecken långt.'), }); // Definiera det initiala tillståndet för vårt formulär export const initialState = { message: '', errors: {}, }; export async function registerUser(prevState, formData) { // 1. Validera formulärdatan const validatedFields = registerSchema.safeParse( Object.fromEntries(formData.entries()) ); // 2. Om valideringen misslyckas, returnera felen if (!validatedFields.success) { return { message: 'Valideringen misslyckades. Kontrollera fälten.', errors: validatedFields.error.flatten().fieldErrors, }; } // 3. (Simulera) Kontrollera om användaren redan finns i databasen // I en riktig app skulle du fråga din databas här. if (validatedFields.data.email === 'user@example.com') { return { message: 'Registreringen misslyckades.', errors: { email: ['Denna e-postadress är redan registrerad.'] }, }; } // 4. (Simulera) Skapa användaren console.log('Skapar användare:', validatedFields.data); // 5. Returnera ett framgångsrikt tillstånd // I en riktig app kan du omdirigera här med `redirect()` från 'next/navigation' return { message: 'Användaren registrerades!', errors: {}, }; }

Denna serveråtgärd är hjärnan i vårt formulär. Den är fristående, säker och ger en tydlig datastruktur för både framgångs- och feltillstånd.

Steg 2: Bygga återanvändbara, statusmedvetna komponenter

För att hålla vår huvudsakliga formulärkomponent ren skapar vi dedikerade komponenter för våra inmatningar och submit-knappen.

Fil: components/SubmitButton.js

'use client'; import { experimental_useFormStatus as useFormStatus } from 'react-dom'; export function SubmitButton({ label }) { const { pending } = useFormStatus(); return ( {pending ? 'Bearbetar...' : label} ); }

Observera användningen av `aria-disabled={pending}`. Detta är en viktig tillgänglighetspraxis som säkerställer att skärmläsare tillkännager det inaktiverade tillståndet korrekt.

Steg 3: Montera huvudformuläret med `useFormState`

Låt oss nu sammanföra allt i vår huvudsakliga formulärkomponent. Vi använder `useFormState` för att ansluta vårt UI till åtgärden `registerUser`.

Fil: components/RegistrationForm.js

'use client'; import { experimental_useFormState as useFormState } from 'react-dom'; import { registerUser, initialState } from '../actions/authActions'; import { SubmitButton } from './SubmitButton'; export function RegistrationForm() { const [state, formAction] = useFormState(registerUser, initialState); return (

Registrera

{state?.message && !state.errors &&

{state.message}

} {state?.message && state.errors &&

{state.message}

}

Användarnamn {state?.errors?.username && (

{state.errors.username[0]}

)}

E-post {state?.errors?.email && (

{state.errors.email[0]}

)}

Lösenord {state?.errors?.password && (

{state.errors.password[0]}

)}

); }

Denna komponent är nu deklarativ och ren. Den hanterar inget tillstånd själv, förutom `state`-objektet som tillhandahålls av `useFormState`. Dess enda uppgift är att återge UI baserat på det tillståndet. Logiken för att inaktivera knappen är inkapslad i `SubmitButton`, och all valideringslogik finns i `authActions.js`. Denna separation av intressen är en stor vinst för underhållbarheten.

Avancerade tekniker och professionella bästa praxis

Medan det grundläggande mönstret är kraftfullt, kräver verkliga applikationer ofta mer nyans. Låt oss utforska några avancerade tekniker.

Hybridmetoden: Sammanfoga omedelbar och efterinlämningsvalidering

Statusbaserad validering är utmärkt för serverkontroller, men att vänta på en nätverksrundresa för att tala om för en användare att deras e-post är ogiltig kan vara långsamt. En hybridmetod är ofta bäst:

• Använd HTML5-validering: Glöm inte grunderna! Attribut som `required`, `type="email"`, `minLength` och `pattern` ger omedelbar, webbläsarnativ feedback utan kostnad.
• Lätt klientsidvalidering: För rent kosmetiska eller formateringskontroller (t.ex. indikator för lösenordsstyrka) kan du fortfarande använda en minimal mängd `useState`- och `onChange`-hanterare.
• Server-sidans auktoritet: Reservera serveråtgärden för den mest kritiska valideringen av affärslogik som inte kan göras på klienten (t.ex. kontrollera unika användarnamn, validera mot databasposter).

Detta ger dig det bästa av två världar: omedelbar feedback för enkla fel och auktoritativ validering för komplexa regler.

Tillgänglighet (A11y): Bygga formulär för alla

Tillgänglighet är icke förhandlingsbar. När du implementerar statusbaserad validering, tänk på dessa punkter:

• Tillkännage fel: I vårt exempel använde vi `aria-live="polite"` på felmeddelandebehållarna. Detta talar om för skärmläsare att tillkännage felmeddelandet så snart det visas, utan att avbryta användarens aktuella flöde.
• Koppla fel till inmatningar: För en mer robust anslutning, använd attributet `aria-describedby`. Inmatningen kan peka på ID:t för dess felmeddelandebehållare och skapa en programmatisk länk.
• Fokusadministration: Efter en inlämning med fel, överväg att programmatiskt flytta fokus till det första ogiltiga fältet. Detta sparar användare från att behöva söka efter vad som gick fel.

Optimistiskt UI med `useFormStatus`s `data`-egenskap

Föreställ dig en app för sociala medier där en användare publicerar en kommentar. Istället för att visa en snurrare under en sekund kan du få appen att kännas omedelbar. `data`-egenskapen från `useFormStatus` är perfekt för detta.

När formuläret skickas in blir `pending` sant och `data` fylls i med `FormData` för inlämningen. Du kan omedelbart återge den nya kommentaren i ett tillfälligt, 'väntande' visuellt tillstånd med hjälp av dessa `data`. Om serveråtgärden lyckas ersätter du den väntande kommentaren med de slutliga data från servern. Om det misslyckas kan du ta bort den väntande kommentaren och visa ett fel. Detta får applikationen att kännas otroligt lyhörd.

Navigera i "experimentella" vatten

Det är avgörande att ta itu med prefixet "experimentell" i `experimental_useFormStatus` och `experimental_useFormState`.

Vad "Experimentell" verkligen betyder

När React märker ett API som experimentellt, betyder det:

• API:et kan ändras: Namnet, argumenten eller returvärdena kan ändras i en framtida React-version utan att följa standardsemantisk versionering (SemVer) för brytande ändringar.
• Det kan finnas buggar: Som en ny funktion kan den ha kantfall som ännu inte är helt förstådda eller lösta.
• Dokumentationen kan vara gles: Medan kärnkoncepten är dokumenterade kan detaljerade guider om avancerade mönster fortfarande utvecklas.

När man ska anta och när man ska vänta

Så, ska du använda det i ditt projekt? Svaret beror på ditt sammanhang:

• Bra för: Personliga projekt, interna verktyg, startups eller team som är bekväma med att hantera potentiella API-ändringar. Att använda det inom en ram som Next.js (som har integrerat dessa funktioner i sin App Router) är i allmänhet en säkrare satsning, eftersom ramverket kan hjälpa till att abstrahera bort en del av omrörningen.
• Använd med försiktighet för: Storskaliga företagsapplikationer, uppdragskritiska system eller projekt med långsiktiga underhållskontrakt där API-stabilitet är av största vikt. I dessa fall kan det vara klokt att vänta tills krokarna befordras till ett stabilt API.

Håll alltid ett öga på den officiella React-bloggen och dokumentationen för tillkännagivanden angående stabiliseringen av dessa krokar.

Slutsats: Formulärs framtid i React

Introduktionen av `experimental_useFormStatus` och dess relaterade API:er är mer än bara ett nytt verktyg; det representerar ett filosofiskt skifte i hur vi bygger interaktiva upplevelser med React. Genom att omfamna webbplattformens grunder och samlokalisera tillståndskänslig logik på servern kan vi bygga applikationer som är enklare, mer motståndskraftiga och ofta mer presterande.

Vi har sett hur `useFormStatus` tillhandahåller ett rent, frikopplat sätt för komponenter att reagera på en formulärinlämnings livscykel. Det eliminerar prop-borrning för väntande tillstånd och möjliggör eleganta, fristående UI-komponenter som en smart `SubmitButton`. I kombination med `useFormState` låser den upp det kraftfulla mönstret med statusbaserad validering, där servern är den ultimata auktoriteten och klientens huvudansvar är att återge tillståndet som returneras av serveråtgärden.

Medan "experimentell"-taggen motiverar en viss försiktighet, är riktningen tydlig. Framtiden för formulär i React är en progressiv förbättring, förenklad tillståndshantering och en kraftfull, sömlös integration mellan klient- och serverlogik. Genom att bemästra dessa nya krokar idag lär du dig inte bara ett nytt API; du förbereder dig för nästa generations webbapplikationsutveckling med React.